Methods, systems and apparatus to improve boot efficiency

ABSTRACT

Methods, apparatus, systems and articles of manufacture are disclosed to improve boot efficiency. An example apparatus includes a firmware support package (FSP) configuration engine to retrieve an FSP reset (FSP-R) component from a platform memory, a firmware interface table (FIT) manager to assign an entry to a FIT for the FSP-R component and assign respective entries to the FIT for auxiliary FSP components, and an FSP configuration engine to transfer platform control to the FSP-R component to control execution of the auxiliary FSP components in response to a platform reset vector.

FIELD OF THE DISCLOSURE

This disclosure relates generally to platform initialization, and, moreparticularly, to methods, systems and apparatus to improve bootefficiency.

BACKGROUND

In recent years, platform developers have created specialized hardwaredevices for user-specific purposes. Some specialized hardware deviceshave emerged from efforts associated with the Internet of Things (IoT),which typically includes specialized hardware devices having arelatively low price point to meet specific information gatheringobjectives.

In some examples, the IoT applications involve embedded systems that areproprietary and/or otherwise closed systems with dedicatedfunctionalities. As such, these closed systems may have unique and/orotherwise customized firmware requirements during boot and/or runtimeexecution.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic illustration of an example platform including afirmware support package reset component to improve boot efficiency.

FIG. 2 is an example firmware interface table generated by the exampleplatform to improve boot efficiency.

FIGS. 3A, 3B and 4 are flowcharts representative of example machinereadable instructions that may be executed to implement the examplefirmware support package reset component, the example configurationengine and/or the example platform of FIG. 1.

FIG. 5 is a block diagram of an example processor platform structured toexecute the example machine readable instructions of FIGS. 3A, 3B and 4to implement the example firmware support package reset component, theexample configuration engine and/or the example platform of FIG. 1.

DETAILED DESCRIPTION

Developers of processor-based devices require such devices to boot in amanner consistent with specifications outlined by a manufacturer of thetype of processor selected by the developers. In examples related topersonal computers (PCs), boot operations may be managed by basicinput/output systems (BIOS) and/or unified extensible firmware interface(UEFI). As used herein, references to “BIOS” refer to the process and/ormechanism by which a platform is booted from a previously powered-offstate. Generally speaking, boot operations occur immediately after poweris applied to a platform, but prior to an operational point where anoperating system (OS) has control of that platform. The boot operationsinitialize platform hardware (e.g., memory, buses, drives, keyboards,displays, etc.) so that such hardware is in a state to be handed-off tothe OS.

While the PC industry has a mature market for BIOS vendors, otherindustries may not produce devices that work with current BIOS vendorsolutions. Internet-of-Things (IoT) devices may include specializedplatforms having components and/or configurations that do not align withthe generalized expectations of BIOS vendor solutions. As such,developers of IoT devices typically design, code and test customizedplatform boot solutions (e.g., bootloaders). In some examples,customizing the BIOS involves engaging BIOS vendors for developmentexpertise and/or licensing to use one or more BIOS solution(s). Even incircumstances where a BIOS vendor agrees to license one or moresolutions to facilitate platform booting, such solutions may remainproprietary, thereby leaving the platform developer with a degree ofdependence upon outside expertise rather than a controlled and/orotherwise fully owned platform solution.

The platform developer is typically knowledgeable of key aspects of theplatform being developed, particularly with regard to on-board sensorsand/or devices. However, many platform developers still rely on thirdparty vendors for processing resources (e.g., processors,microprocessors, microcontrollers and/or, more generally, processingsilicon). While the platform developers may have expertise in mostaspects of their platform, gaining similar expertise and/or knowledgeregarding the processing resources and/or processing resourceinitialization requirements may require adherence to voluminous and/orcomplicated processing vendor specifications and manuals.

To relinquish valuable developer development time, firmware supportpackage (FSP) components (e.g., binaries, application programminginterfaces (APIs)) facilitate a focused configuration effort ofprocessing resources of a platform. In some examples, the FSP componentsare associated with the Intel® Firmware Support Package (FSP). Ratherthan require the developer to become an expert in third party processingresources, the FSP components allow the processing resources to beproperly initialized during a booting phase of the platform through abootloader (e.g., coreboot or EDK II). Upon completion of processingresource initialization via the FSP components, developer-specific bootinstructions may be implemented to continue with initialization of oneor more other portions of the platform for which the developer likelyhas expertise.

Example FSP components include a temporary memory (e.g., random accessmemory (RAM)) initialization component, referred to herein as “FSP-T,”which establishes temporary memory for a platform of interest. Generallyspeaking, when a platform is first powered-on there is no availablememory within which to establish a stack. Without a stack, programminginstructions for an associated processor must be written in an assemblyformat, which is relatively less convenient and/or efficient whencompared to a native language type, such as C. In some examples, FSP-Tuses a portion of processor cache as the temporary memory.

Example FSP components also include a memory initialization component,referred to herein as “FSP-M,” which initializes permanent memory inlieu of previously created temporary memory, thereby relinquishing thecache for processor utilization purposes. Additionally, example FSPcomponents also include a silicon initialization component, referred toherein as “FSP-S,” which initializes processor silicon, such as acentral processing unit (CPU), input/output (I/O) controller, etc.Because processor silicon is complex and requires strict adherence tomanufacturer initialization specifications and/or processes, someplatform developers do not possess the expertise necessary for propersilicon initialization. Accordingly, the example FSP-S componentencapsulates necessary initialization information and/or proceduresthat, when integrated within a platform bootloader, allows the platformto properly initialize.

While example FSP components described above may assist the platformdeveloper during boot operations, examples disclosed herein facilitateconsistent management and/or guidance of such example FSP components.Traditionally, the example platform developer is required to build aboot process that includes appropriate ones of the FSP components, whichare specific to silicon to be used on the platform. Examples disclosedherein verify that one or more FSP components are compatible withplatform silicon. Additionally, some platforms include particular memorytypes that may be available for stack initialization, thereby removing aneed for the example FSP-T component to be invoked. Memoryinitialization is one of the largest consumers of time during a bootprocess of a platform, thus invoking one or more additionalinitialization processes when not necessary adds to an overall bootduration of the platform.

FIG. 1 is a portion of an example platform 100 to improve bootefficiency. In the illustrated example of FIG. 1, the platform 100includes a processor 102 communicatively connected to a bus 104 that iscommunicatively connected to static random access memory (SRAM) 106 andflash memory 108. In some examples, the platform 100 may not include theexample SRAM 106, as described in further detail below. While theillustrated example of FIG. 1 shows the SRAM 106 outside the structureof the example processor 102, examples disclosed herein are not limitedthereto. In some examples, the SRAM 106 may be part of a die of theexample processor 102, and may operate as a type of cache RAM. In otherexamples, the platform 100 may not include the example SRAM 106 and,instead, include other memory that is not initialized, thereby requiringone or more services of a memory initialization component to get thatmemory ready for use. Generally speaking, the example SRAM 106 is arelatively expensive type of RAM that is relatively faster than dynamicRAM (DRAM), does not require periodic refresh cycle(s), and can retainmemory contents in view of a loss of power (e.g., non-volatile SRAMtypes).

The example flash memory 108 includes a basic input/output system (BIOS)110 to facilitate, in part, boot operation(s) of the example platform100. In the illustrated example of FIG. 1, the BIOS 110 includes anFSP-reset (FSP-R) component 112, and one or more auxiliary FSPcomponents, such as an FSP-temporary (FSP-T) component 114, anFSP-memory initialization (FSP-M) component 116 and an FSP-silicon(FSP-S) component 118. Additionally, the example BIOS 110 includes anexample firmware interface table (FIT) 120, an example bootloader 122,an example boot policy manifest (BPM) 124, and an example FSPconfiguration engine 126.

The example FSP-R component 112 includes an example FSP authenticationmanager 128, an example FSP patch manager 130, an example FSP/FITinterface 132, an example BPM interface 134, an example processor modemanager 136, an example platform memory analyzer 138, and an example FSPcomponent analyzer 140. The example FSP configuration engine 126includes an example binary configuration tool (BCT) interface 142, anexample power manager 146, and an example FIT manager 148.

In operation, the example processor 102 determines whether a power-oncondition has occurred, such as by way of an invocation of a resetaddress. If so, the example reset address points to code locatedsomewhere on the example platform 100 to begin platform initialization.In some examples, the reset address points to a firmware interface table(FIT) 120, which is an example data structure containing addressinformation for one or more firmware volumes (FVs), such as an FVassociated with the example FSP-R component 112 and/or an FV associatedwith one or more of the example auxiliary FSP components (e.g., theexample FSP-T component 114, the example FSP-M component 116, theexample FSP-S component 118, etc.). In the event the example FIT 120identifies a corresponding FSP-R component 112, then the example FSPauthentication manager authenticates the FSP-R component 112 and beginsplatform initialization, as described in further detail below. However,in the event the example FIG. 120 does not identify a correspondingFSP-R component 112, then the example FSP configuration engine 126 isinvoked to determine whether to configure the example platform 100 toemploy and/or otherwise utilize an FSP-R component 112.

In some examples, the FSP configuration engine 126 initiates platformcustomization to employ and/or otherwise utilize the FSP-R component112, such as a response to user installation of a binary configurationtool (BCT) that installs one or more of the FSP-T component 114 (e.g.,to initialize temporary memory), the FSP-M component 116 (e.g., toinitialize permanent memory), and/or the FSP-S component 118 (e.g., toinitialize platform silicon, such as a processor and/or CPU). Theexample BCT interface 142 invokes the BCT utilized by the user when oneor more FSP components were added to the example platform 100. In someexamples, the BCT interface 142 retrieves installation details of theFSP components, such as version numbers, address location values (e.g.,offset values), and/or target silicon to which the FSP components aretailored and/or otherwise designed to configure. As described in furtherdetail below, acquiring such installation details facilitates an abilityto verify that correct FSP components have been installed by a platformmanager (e.g., user) in view of specific platform hardware (e.g., aspecific processor and/or processor components).

The example FIT manager 148 accesses the example FIT 120 located in theBIOS 110 and assigns a starting address for the FSP-R component 112 sothat it can begin execution in response to a power-up state (afterpreviously being powered-off, or in response to a power-reset request).Generally speaking, the example FSP-R component 112 facilitates theability to dispatch the proper auxiliary FSP components (e.g., verifycompatibility with platform silicon), a particular order of dispatch(e.g., an execution order of the example auxiliary FSP components),and/or blocking dispatch of particular auxiliary FSP components whenthey may not be needed during platform initialization. In other words,the example FSP-R component allows deployment of the correct auxiliaryFSP components for the correct platform silicon (e.g., processor).Additionally, the example FIT manager 148 assigns starting addresses inthe example FIG. 120 to point to corresponding auxiliary FSP components,such as the example FSP-T component 114, the example FSP-M component 116and/or the example FSP-S component 118. FIG. 2 illustrates the exampleFIT 120 of FIG. 1. In the illustrated example of FIG. 2, the FIT 120includes a FIT table pointer starting address 202 configured by theexample FIT manager 148. In some examples the FIT 120 includes a legacyreset vector 204, and the example FIT manager 148 may modify the FIT 120to redirect to the example FIT starting address 202. The example FITmanager 148 updates the FIT 120 to include appropriate startingaddresses for FVs of interest, such as a FIT header address 206, anFSP-R pointer 208 directed to an FSP-R starting address 210, and a BPMpointer 212 to identify an FSP-T starting address 214, an FSP-M startingaddress 216, and an FSP-S starting address 218. After the example FIT120 has been configured to employ and/or otherwise utilize the exampleFSP-R component 112, the example power manager 146 cycles power to theexample platform 100.

Upon power-on of the example platform 100, the example processor 102reset vector points to the example FIT pointer starting address 202 andlocates the example FSP-R component starting address 210. To verify thatthe example FSP-R component 112 is trusted, the example FSPauthentication manager 128 extends trust by performing authentication ofthe FSP-R component 112, such as via a private key/public key pairing.For example, the FSP-R component 112 may have been created in view of aprivate key available only to the manufacturer so that a comparison hashcan be performed to verify authenticity. In the event the example FSP-Rcomponent 112 does not pass an authentication test, then the example FSPauthentication manager does not allow further execution, operationand/or control by the example FSP-R component 112. On the other hand, inthe event the example FSP-R component 112 passes one or moreauthentication test(s), then the example FSP patch manager 130determines whether a patch is needed.

In some examples, the manufacturer of the silicon being used on theexample platform 100 desires an updated version of the FSP-R component112 to be used. Reasons for distributing the updated version of theFSP-R component 112 (e.g., the patch) include correction of discoveredbugs (e.g., coding errors, design flaws, etc.), updated features and/oralternate flow directives of one or more FSP components (e.g., FSP-T114, FSP-M 116, FSP-S 118). The example FSP authentication manager 128authenticates patch component(s), and in some examples the new FSP-Rcomponent may include an alternate/new address to be identified in theexample FIT 120, which is updated by the example FSP/FIT interface 132.To enable any new authenticated patch, the example FSP-R component 112may invoke a platform power reset instruction so that the example FIT120 can point to and begin application of the updated/patched FSP-Rcomponent 112.

However, in the event the example FSP patch manager 130 determines thata patch is not needed, then the example FSP configuration engine 126transfers control to the example FSP-R component 112, and the exampleBPM interface 134 locates and verifies the boot policy manifest (e.g.,using an original equipment manufacturer (OEM) public key). In the eventthe BPM 124 does not pass one or more verification test(s), then theexample FSP authentication manager 128 instructs the example platform100 to proceed with a legacy boot process, thereby bypassing the exampleFSP-R component 112. On the other hand, in response to the example BPM124 passing one or more verification test(s), the example FSP-Rcomponent 112 facilitates an improved platform initialization process,as described in further detail below.

The example processor mode manager 136 switches the example processor102 to an alternate bit mode (e.g., a thirty-two (32) bit mode) so thatstack access may occur and, thus, FVs can be executed using one or morenative languages rather than low-level assembly code. The exampleplatform memory analyzer 138 determines whether the platform 100requires one or more services of the example FSP-T component 114. Forexample, while a user of the example platform 100 may have employed abinary configuration tool (BCT) to install one or more FSP componentsthat are associated with the platform silicon (e.g., the exampleprocessor 102), one or more of those FSP components may not actually berequired during one or more phases of platform initialization. In someexamples, the platform includes the example SRAM 106 in an initializedstate. If so, then a default attempt to invoke the example FSP-Tcomponent 114 results in wasted processing efforts and longer bootdurations for the example platform 100. Accordingly, the exampleplatform memory analyzer 138 reduces wasted processor cycles and reducesplatform boot durations by preventing the invoking of the example FSP-Tcomponent 114 when the example platform 100 already includes a suitablememory (e.g., the SRAM 106) that is initialized.

When temporary memory has been established (e.g., either by applicationof the example FSP-T component 114 or by virtue of an existinginitialized memory (e.g., SRAM 106)), the example platform memoryanalyzer 138 sets up a stack in the temporary memory so that anysubsequent calls to one or more FVs can take advantage of nativelanguage code. The example FSP component analyzer 140 locates theexample FSP-M component 116 that was installed via the BCT. As describedabove, while temporary memory is established and utilized for earlyphases of platform booting activity, one or more subsequent phasesestablishes permanent memory, such as RAM. The example FSP-M component116 is chartered with the responsibility of establishing the permanentmemory and, once established, the example platform memory analyzer 138migrates the previously established temporary memory to the permanentmemory. As described above, in some circumstances a platform may haveone or more previously established and/or otherwise initializedpermanent memory resources available for platform use. If so, then theexample FSP component analyzer 140 may block invocation of the exampleFSP-M component 116 in an effort to further conserve processingresources and reduce initialization duration.

The example FSP component analyzer 140 locates the example FSP-Scomponent 118 that was installed via the BCT. The example FSP-Scomponent 118 is chartered with the responsibility of initializing thesilicon used by the example platform 100. As described above, to reduceone or burdens on the user when developing the platform 100, the FSP-Scomponent 118 handles silicon-specific initialization tasks so that thedeveloper can focus on one or more functional objectives of the platform(e.g., IoT sensor reading objectives). After the example FSP-S component118 completes silicon initialization, the example BPM interface 134hands control to the OEM boot block for boot initialization task(s)associated with other portions of the example platform.

While an example manner of implementing the platform of FIG. 1 isillustrated in FIGS. 1 and 2, one or more of the elements, processesand/or devices illustrated in FIGS. 1 and/or 2 may be combined, divided,re-arranged, omitted, eliminated and/or implemented in any other way.Further, the example FSP-R component 112, the example auxiliary FSPcomponents (e.g., the example FSP-T component 114, the example FSP-Mcomponent 116, the example FSP-S component 118), the example FIT 120,the example FSP configuration engine 126, the example FSP authenticationmanager 128, the example FSP patch manager 130, the example FSP/FITinterface 132, the example BPM interface 134, the example processor modemanager 136, the example platform memory analyzer 138, the example FSPcomponent analyzer 140, the example BCT interface 142, the example powermanager 146, the example FIT manager 148 and/or, more generally, theexample platform 100 of FIGS. 1 and 2 may be implemented by hardware,software, firmware and/or any combination of hardware, software and/orfirmware. Thus, for example, any of the example FSP-R component 112, theexample auxiliary FSP components (e.g., the example FSP-T component 114,the example FSP-M component 116, the example FSP-S component 118), theexample FIT 120, the example FSP configuration engine 126, the exampleFSP authentication manager 128, the example FSP patch manager 130, theexample FSP/FIT interface 132, the example BPM interface 134, theexample processor mode manager 136, the example platform memory analyzer138, the example FSP component analyzer 140, the example BCT interface142, the example power manager 146, the example FIT manager 148 and/or,more generally, the example platform 100 of FIGS. 1 and 2 could beimplemented by one or more analog or digital circuit(s), logic circuits,programmable processor(s), application specific integrated circuit(s)(ASIC(s)), programmable logic device(s) (PLD(s)) and/or fieldprogrammable logic device(s) (FPLD(s)). When reading any of theapparatus or system claims of this patent to cover a purely softwareand/or firmware implementation, at least one of the example FSP-Rcomponent 112, the example auxiliary FSP components (e.g., the exampleFSP-T component 114, the example FSP-M component 116, the example FSP-Scomponent 118), the example FIT 120, the example FSP configurationengine 126, the example FSP authentication manager 128, the example FSPpatch manager 130, the example FSP/FIT interface 132, the example BPMinterface 134, the example processor mode manager 136, the exampleplatform memory analyzer 138, the example FSP component analyzer 140,the example BCT interface 142, the example power manager 146, theexample FIT manager 148 and/or, more generally, the example platform 100of FIGS. 1 and 2 is/are hereby expressly defined to include a tangiblecomputer readable storage device or storage disk such as a memory, adigital versatile disk (DVD), a compact disk (CD), a Blu-ray disk, etc.storing the software and/or firmware. Further still, the example FSP-Rcomponent 112, the example auxiliary FSP components (e.g., the exampleFSP-T component 114, the example FSP-M component 116, the example FSP-Scomponent 118), the example FIT 120, the example FSP configurationengine 126, the example FSP authentication manager 128, the example FSPpatch manager 130, the example FSP/FIT interface 132, the example BPMinterface 134, the example processor mode manager 136, the exampleplatform memory analyzer 138, the example FSP component analyzer 140,the example BCT interface 142, the example power manager 146, theexample FIT manager 148 and/or, more generally, the example platform 100of FIGS. 1 and 2 may include one or more elements, processes and/ordevices in addition to, or instead of, those illustrated in FIGS. 1and/or 2, and/or may include more than one of any or all of theillustrated elements, processes and devices.

Flowcharts representative of example machine readable instructions forimplementing the platform 100 of FIG. 1 is shown in FIGS. 3A, 3B and 4.In these examples, the machine readable instructions comprise a programfor execution by a processor such as the processor 512 shown in theexample processor platform 500 discussed below in connection with FIG.5. The program(s) may be embodied in software stored on a tangiblecomputer readable storage medium such as a CD-ROM, a floppy disk, a harddrive, a digital versatile disk (DVD), a Blu-ray disk, or a memoryassociated with the processor 512, but the entire program(s) and/orparts thereof could alternatively be executed by a device other than theprocessor 512 and/or embodied in firmware or dedicated hardware.Further, although the example program(s) is/are described with referenceto the flowchart illustrated in FIGS. 3A, 3B and 4, many other methodsof implementing the example platform 100 may alternatively be used. Forexample, the order of execution of the blocks may be changed, and/orsome of the blocks described may be changed, eliminated, or combined.

As mentioned above, the example processes of FIGS. 3A, 3B and 4 may beimplemented using coded instructions (e.g., computer and/or machinereadable instructions) stored on a tangible computer readable storagemedium such as a hard disk drive, a flash memory, a read-only memory(ROM), a compact disk (CD), a digital versatile disk (DVD), a cache, arandom-access memory (RAM) and/or any other storage device or storagedisk in which information is stored for any duration (e.g., for extendedtime periods, permanently, for brief instances, for temporarilybuffering, and/or for caching of the information). As used herein, theterm tangible computer readable storage medium is expressly defined toinclude any type of computer readable storage device and/or storage diskand to exclude propagating signals and to exclude transmission media. Asused herein, “tangible computer readable storage medium” and “tangiblemachine readable storage medium” are used interchangeably. Additionallyor alternatively, the example processes of FIGS. 3A, 3B and 4 may beimplemented using coded instructions (e.g., computer and/or machinereadable instructions) stored on a non-transitory computer and/ormachine readable medium such as a hard disk drive, a flash memory, aread-only memory, a compact disk, a digital versatile disk, a cache, arandom-access memory and/or any other storage device or storage disk inwhich information is stored for any duration (e.g., for extended timeperiods, permanently, for brief instances, for temporarily buffering,and/or for caching of the information). As used herein, the termnon-transitory computer readable medium is expressly defined to includeany type of computer readable storage device and/or storage disk and toexclude propagating signals and to exclude transmission media. As usedherein, when the phrase “at least” is used as the transition term in apreamble of a claim, it is open-ended in the same manner as the term“comprising” is open ended.

The program 300 of FIG. 3A begins at block 302 where the exampleprocessor 102 determines whether a power-on condition has occurred and,if so, the example FIT 120 searches for an FSP-R component 112 (block304). In the event an FSP-R component 112 is not identified in the FIT120 (block 306), then the FIT 120 may not yet be configured to operatewith the FSP-R component 112 and/or one or more other FSP components,such as the example FSP-T component 114, the example FSP-M component 116and/or the example FSP-S component 118. The example FSP configurationengine 126 determines whether the example platform 100 is to beconfigured to employ the FSP-R component 112 (block 308), as describedbelow in connection with FIG. 3B.

In the illustrated example of FIG. 3B, the example FSP configurationengine 126 determines whether the platform is to be configured to employthe FSP-R component 112 (block 310) and, if not, control of the platformis directed to a legacy boot process (block 311). On the other hand, inthe event the platform is to be configured to employ the FSP-R component112 (block 310), then the example FSP configuration engine 126 retrievesthe FSP-R component 112 stored in the example flash memory 108 (e.g.,stored within the example BIOS 110) and the example BCT interface 142invokes the BCT (block 312), which was utilized by the user on a prioroccasion when one or more FSP components were added to the exampleplatform 100. This facilitates information gathering of the FSPcomponents that have been installed on the platform 100, such as FSPcomponent names, offset address information (e.g., to be added to theexample FIT 120), etc. The example FIT manager 148 accesses the FIT 120(block 314), assigns a starting address for the example FSP-R component112 (block 316), and assigns starting address pointers for the other FSPcomponents (block 318), such as the example FSP-T 114, the example FSP-Mcomponent 116, and/or the example FSP-S component 118. Upon completionof configuration of the example FIT 120, the example power manager 146invokes a power-reset directive for the platform 100 (block 320) so thatthe example FSP-R component 112 can be invoked in response to theprocessor reset vector.

Returning to the illustrated example of FIG. 3A, in the event theexample FSP-R component 112 is located in the example FIT 120 (block306) (e.g., because the example FSP-R component 112 has previously beenconfigured on the platform 100), the example FSP authentication manager128 performs an authentication test of the example FSP-R component 112(block 322). In the event the authentication test fails (block 324),then control is directed to a legacy boot process for concern that theFSP-R component 112 cannot be trusted (block 326). However, in the eventthe authentication test is successful (block 324), then the example FSPpatch manager 130 determines if a patch is needed (block 328). Forexample, when a manufacturer of the example FSP-R component 112 has anupdated version for distribution, such as an updated FSP-R component 112installed via a boot configuration tool on a prior occasion, a flag inthe example FSP patch manager 130 may be set to initiate a patch updateprocess (block 328). As described above, updated versions of the FSP-Rcomponent 112 may be distributed in view of design flaw corrections,feature improvements and/or other changes, thereby allowing theprocessor 102 microcode to point to a correct/updated version, asneeded.

The example FSP authentication manager 128 authenticates the patchedversion of the example FSP-R component 112 (block 330), and the exampleFSP/FIT interface 132 updates the example FIT 120 to refer-to and/orotherwise reference the patched version of the FSP-R component 112(block 332). The example FSP patch manager 130 then invokes a platformpower reset directive (block 334), and control returns to block 302.

Returning to block 328, in the event a patch is not needed, then theexample FSP configuration engine 126 transfers control to the FSP-Rcomponent 112 (block 336) and the example BPM interface 134 locates andverifies the example BPM 124 (block 338) (e.g., using an OEM providedpublic key). If the verification of the example BPM is not successful(block 340), then the example FSP authentication manager 128 directscontrol to a legacy boot process out of concern that the BPM cannot betrusted (block 326). On the other hand, in the event the BPM is verified(block 340), then the example FSP-R component 112 initiates FSP-Rsequencing (block 342), as described below in connection with FIG. 4.

In the illustrated example of FIG. 4, the example processor mode manager136 switches the example processor 102 to operate in a thirty-two (32)bit mode (block 402) so that FVs can be executed using one or morenative languages rather than low-level assembly code. The exampleplatform memory analyzer 138 determines whether the example FSP-Tcomponent 114 is needed (block 404). As described above, memoryinitialization activities of platforms is one of the most time-consumingboot related activities. Accordingly, examples disclosed hereinfacilitate a manner to evaluate the need for such activities in view ofpotentially available platform resources, such as already availablememory in an initialized state (e.g., SRAM). When such resources arefound, examples disclosed herein facilitate an opportunity to restrict,block and/or otherwise prevent unnecessary initialization operation(s)from being executed, thereby conserving processing resources andreducing platform initialization duration.

In the event the example FSP-T component 114 is to be invoked (block404), then the example FSP component analyzer 140 locates and invokesthe FSP-T component 114 (block 406) to initialize temporary memory. Theexample platform memory analyzer 138 sets-up a stack in the temporarymemory (block 408) for use by one or more FVs. In some examples, eachFSP component may be tested to confirm that it is the correct FSPcomponent in view of silicon resources of the example platform 100(block 406). For example, while the user may have previously invoked theboot configuration tool for the purpose of installing one or more FSPcomponents, the possibility exists that an incorrect FSP component hasbeen installed. If so, then the example FSP component analyzer 140 mayinvoke an error message and/or divert control to a legacy boot processuntil appropriate FSP component(s) can be identified and installed onthe platform 100 (e.g., stored in the example flash memory 108). Inother examples, FSP component verification checks may occur inconnection with the example program 308 of FIG. 3B.

The example FSP component analyzer 140 locates and invokes the exampleFSP-M component 116 (block 410) to set up permanent memory, and theexample platform memory analyzer 138 migrates the temporary stack to thepermanent memory (block 412). As described above, the example FSPcomponent analyzer 140 may perform another verification check to makesure that the appropriate FSP component(s) are being used in view ofcompatible platform resource(s) (block 410). The example FSP componentanalyzer 140 locates and invokes the example FSP-S component 118 (block414) to initialize the silicon (e.g., the processor 102) used by theexample platform 100. Upon completion of silicon initialization (block414), the example BPM interface 134 hands off control to the OEM bootblock to facilitate initialization of one or more remaining platform 100resources (block 416).

FIG. 5 is a block diagram of an example processor platform 500 capableof executing the instructions of FIGS. 3A, 3B and/or 4 to implement theFSP-R component 112, the FSP configuration engine 126 and, moregenerally, the platform 100 of FIG. 1. The processor platform 500 canbe, for example, a server, a personal computer, a mobile device (e.g., acell phone, a smart phone, a tablet such as an iPad™), a personaldigital assistant (PDA), an Internet appliance, a DVD player, a CDplayer, a digital video recorder, a Blu-ray player, a gaming console, apersonal video recorder, a set top box, or any other type of computingdevice, such as IoT devices.

The processor platform 500 of the illustrated example includes aprocessor 512. The processor 512 of the illustrated example is hardware.For example, the processor 512 can be implemented by one or moreintegrated circuits, logic circuits, microprocessors or controllers fromany desired family or manufacturer.

The processor 512 of the illustrated example includes a local memory 513(e.g., a cache). The processor 512 of the illustrated example is incommunication with a main memory including a volatile memory 514 and anon-volatile memory 516 via a bus 518. The volatile memory 514 may beimplemented by Synchronous Dynamic Random Access Memory (SDRAM), DynamicRandom Access Memory (DRAM), RAMBUS Dynamic Random Access Memory (RDRAM)and/or any other type of random access memory device. The non-volatilememory 516 may be implemented by flash memory and/or any other desiredtype of memory device. Access to the main memory 514, 516 is controlledby a memory controller.

The processor platform 500 of the illustrated example also includes aninterface circuit 520. The interface circuit 520 may be implemented byany type of interface standard, such as an Ethernet interface, auniversal serial bus (USB), and/or a PCI express interface.

In the illustrated example, one or more input devices 522 are connectedto the interface circuit 520. The input device(s) 522 permit(s) a userto enter data and commands into the processor 512. The input device(s)can be implemented by, for example, an audio sensor, a microphone, acamera (still or video), a keyboard, a button, a mouse, a touchscreen, atrack-pad, a trackball, isopoint and/or a voice recognition system.

One or more output devices 524 are also connected to the interfacecircuit 520 of the illustrated example. The output devices 524 can beimplemented, for example, by display devices (e.g., a light emittingdiode (LED), an organic light emitting diode (OLED), a liquid crystaldisplay, a cathode ray tube display (CRT), a touchscreen, a tactileoutput device, a printer and/or speakers). The interface circuit 520 ofthe illustrated example, thus, typically includes a graphics drivercard, a graphics driver chip or a graphics driver processor.

The interface circuit 520 of the illustrated example also includes acommunication device such as a transmitter, a receiver, a transceiver, amodem and/or network interface card to facilitate exchange of data withexternal machines (e.g., computing devices of any kind) via a network526 (e.g., an Ethernet connection, a digital subscriber line (DSL), atelephone line, coaxial cable, a cellular telephone system, etc.).

The processor platform 500 of the illustrated example also includes oneor more mass storage devices 528 for storing software and/or data.Examples of such mass storage devices 528 include floppy disk drives,hard drive disks, compact disk drives, Blu-ray disk drives, RAIDsystems, and digital versatile disk (DVD) drives.

The coded instructions 532 of FIGS. 3A, 3B and/or 4 may be stored in themass storage device 528, in the volatile memory 514, in the non-volatilememory 516, and/or on a removable tangible computer readable storagemedium such as a CD or DVD.

From the foregoing, it will be appreciated that the above disclosedmethods, apparatus and articles of manufacture improve an initializationefficiency of a platform. In particular, examples disclosed hereinpermit control of one or more auxiliary FSP components during a bootinitialization process of the platform, verify that a platform manageris using one or more correct auxiliary FSP components, and controls anorder of which ones of the auxiliary FSP components are executed duringthe platform initialization. Additionally, examples disclosed hereinevaluate platform resources and/or platform resource capabilities toblock and/or otherwise prevent execution of one or more auxiliary FSPcomponents to improve (reduce) a duration of the platform initializationprocess.

Example methods, apparatus, systems and articles of manufacture toimprove boot efficiency are disclosed herein. Further examples andcombinations thereof include the following.

Example 1 is an apparatus to improve platform efficiency including afirmware support package (FSP) configuration engine to retrieve an FSPreset (FSP-R) component from a platform memory, a firmware interfacetable (FIT) manager to assign an entry to a FIT for the FSP-R componentand assign respective entries to the FIT for auxiliary FSP components,and an FSP configuration engine to transfer platform control to theFSP-R component to control execution of the auxiliary FSP components inresponse to a platform reset vector.

Example 2 includes the apparatus as defined in example 1, furtherincluding a platform memory analyzer to identify available platformresources associated with respective ones of the auxiliary FSPcomponents.

Example 3 includes the apparatus as defined in example 2, furtherincluding an FSP component analyzer to reduce a boot duration of theplatform by bypassing one of the respective ones of the auxiliary FSPcomponents when respective ones of the available platform resources areavailable.

Example 4 includes the apparatus as defined in example 2, furtherincluding an FSP component analyzer to invoke one of the respective onesof the auxiliary FSP components when respective ones of the availableplatform resources are unavailable.

Example 5 includes the apparatus as defined in example 1, wherein theFSP-R component is to control an execution order of the auxiliary FSPcomponents during platform boot.

Example 6 includes the apparatus as defined in example 1, furtherincluding an FSP component analyzer to verify compatibility betweenrespective ones of the auxiliary FSP components and a platformprocessor.

Example 7 includes the apparatus as defined in example 1, wherein theFSP-R component is to assign a processor of the platform to an alternatebit mode to facilitate stack access.

Example 8 includes the apparatus as defined in example 7, wherein thealternate bit mode includes a 32-bit mode.

Example 9 includes the apparatus as defined in example 1, furtherincluding an FSP patch manager to update the FSP-R component in responseto a patch request.

Example 10 includes the apparatus as defined in example 9, furtherincluding an FSP authentication manager to authenticate an updated FSP-Rcomponent with a public key.

Example 11 includes the apparatus as defined in example 10, furtherincluding an FSP/FIT interface to update the FIT with an updated entryfor the updated FSP-R component.

Example 12 is a method to improve platform efficiency, includingretrieving, with an instruction by a processor, a firmware supportpackage (FSP) reset (FSP-R) component from a platform memory, assigning,with an instruction by the processor, an entry to a firmware interfacetable (FIT) for the FSP-R component, assigning, with an instruction bythe processor, respective entries to the FIT for auxiliary FSPcomponents, and transferring, with an instruction by the processor,platform control to the FSP-R component to control execution of theauxiliary FSP components in response to a platform reset vector.

Example 13 includes the method as defined in example 12, furtherincluding identifying available platform resources associated withrespective ones of the auxiliary FSP components.

Example 14 includes the method as defined in example 13, furtherincluding reducing a boot duration of the platform by bypassing one ofthe respective ones of the auxiliary FSP components when respective onesof the available platform resources are available.

Example 15 includes the method as defined in example 13, furtherincluding invoking one of the respective ones of the auxiliary FSPcomponents when respective ones of the available platform resources areunavailable.

Example 16 includes the method as defined in example 12, furtherincluding controlling an execution order of the auxiliary FSP componentsduring platform boot.

Example 17 includes the method as defined in example 12, furtherincluding verifying compatibility between respective ones of theauxiliary FSP components and a platform processor.

Example 18 includes the method as defined in example 12, furtherincluding assigning a processor of the platform to an alternate bit modeto facilitate stack access.

Example 19 includes the method as defined in example 18, wherein thealternate bit mode includes a 32-bit mode.

Example 20 includes the method as defined in example 12, furtherincluding updating the FSP-R component in response to a patch request.

Example 21 includes the method as defined in example 20, furtherincluding authenticating an updated FSP-R component with a public key.

Example 22 includes the method as defined in example 21, furtherincluding updating the FIT with an updated entry for the updated FSP-Rcomponent.

Example 23 is a tangible computer-readable medium comprisinginstructions which, when executed, cause a processor to at leastretrieve a firmware support package (FSP) reset (FSP-R) component from aplatform memory, assign an entry to a firmware interface table (FIT) forthe FSP-R component, assign respective entries to the FIT for auxiliaryFSP components, and transfer platform control to the FSP-R component tocontrol execution of the auxiliary FSP components in response to aplatform reset vector.

Example 24 includes the computer-readable medium as defined in example23, wherein the instructions, when executed, further cause the processorto identify available platform resources associated with respective onesof the auxiliary FSP components.

Example 25 includes the computer-readable medium as defined in example24, wherein the instructions, when executed, further cause the processorto reduce a boot duration of the platform by bypassing one of therespective ones of the auxiliary FSP components when respective ones ofthe available platform resources are available.

Example 26 includes the computer-readable medium as defined in example24, wherein the instructions, when executed, further cause the processorto invoke one of the respective ones of the auxiliary FSP componentswhen respective ones of the available platform resources areunavailable.

Example 27 includes the computer-readable medium as defined in example23, wherein the instructions, when executed, further cause the processorto control an execution order of the auxiliary FSP components duringplatform boot.

Example 28 includes the computer-readable medium as defined in example23, wherein the instructions, when executed, further cause the processorto verify compatibility between respective ones of the auxiliary FSPcomponents and a platform processor.

Example 29 includes the computer-readable medium as defined in example23, wherein the instructions, when executed, further cause the processorto assign a processor of the platform to an alternate bit mode tofacilitate stack access.

Example 30 includes the computer-readable medium as defined in example29, wherein the instructions, when executed, further cause the processorto assign the processor to a 32-bit mode.

Example 31 includes the computer-readable medium as defined in example23, wherein the instructions, when executed, further cause the processorto update the FSP-R component in response to a patch request.

Example 32 includes the computer-readable medium as defined in example31, wherein the instructions, when executed, further cause the processorto authenticate an updated FSP-R component with a public key.

Example 33 includes the computer-readable medium as defined in example32, wherein the instructions, when executed, further cause the processorto update the FIT with an updated entry for the updated FSP-R component.

Example 34 is a system to improve platform efficiency, including meansfor retrieving a firmware support package (FSP) reset (FSP-R) componentfrom a platform memory, means for assigning an entry to a firmwareinterface table (FIT) for the FSP-R component, means for assigningrespective entries to the FIT for auxiliary FSP components, and meansfor transferring platform control to the FSP-R component to controlexecution of the auxiliary FSP components in response to a platformreset vector.

Example 35 includes the system as defined in example 34, furtherincluding means for identifying available platform resources associatedwith respective ones of the auxiliary FSP components.

Example 36 includes the system as defined in example 35, furtherincluding means for reducing a boot duration of the platform bybypassing one of the respective ones of the auxiliary FSP componentswhen respective ones of the available platform resources are available.

Example 37 includes the system as defined in example 35, furtherincluding means for invoking one of the respective ones of the auxiliaryFSP components when respective ones of the available platform resourcesare unavailable.

Example 38 includes the system as defined in example 34, furtherincluding means for controlling an execution order of the auxiliary FSPcomponents during platform boot.

Example 39 includes the system as defined in example 34, furtherincluding means for verifying compatibility between respective ones ofthe auxiliary FSP components and a platform processor.

Example 40 includes the system as defined in example 34, furtherincluding means for assigning a processor of the platform to analternate bit mode to facilitate stack access.

Example 41 includes the system as defined in example 40, furtherincluding means for assigning the processor to a 32-bit mode.

Example 42 includes the system as defined in example 34, furtherincluding means for updating the FSP-R component in response to a patchrequest.

Example 43 includes the system as defined in example 42, furtherincluding means for authenticating an updated FSP-R component with apublic key.

Example 44 includes the system as defined in example 43, furtherincluding means for updating the FIT with an updated entry for theupdated FSP-R component.

Although certain example methods, apparatus and articles of manufacturehave been disclosed herein, the scope of coverage of this patent is notlimited thereto. On the contrary, this patent covers all methods,apparatus and articles of manufacture fairly falling within the scope ofthe claims of this patent.

1. An apparatus to improve platform efficiency, comprising: a firmwaresupport package (FSP) configuration engine to retrieve an FSP reset(FSP-R) component from a platform memory; a firmware interface table(FIT) manager to: assign an entry to a FIT for the FSP-R component; andassign respective entries to the FIT for auxiliary FSP components; andan FSP configuration engine to transfer platform control to the FSP-Rcomponent to control execution of the auxiliary FSP components inresponse to a platform reset vector.
 2. The apparatus as defined inclaim 1, further including a platform memory analyzer to identifyavailable platform resources associated with respective ones of theauxiliary FSP components.
 3. The apparatus as defined in claim 2,further including an FSP component analyzer to reduce a boot duration ofthe platform by bypassing one of the respective ones of the auxiliaryFSP components when respective ones of the available platform resourcesare available.
 4. The apparatus as defined in claim 2, further includingan FSP component analyzer to invoke one of the respective ones of theauxiliary FSP components when respective ones of the available platformresources are unavailable.
 5. The apparatus as defined in claim 1,wherein the FSP-R component is to control an execution order of theauxiliary FSP components during platform boot.
 6. The apparatus asdefined in claim 1, further including an FSP component analyzer toverify compatibility between respective ones of the auxiliary FSPcomponents and a platform processor.
 7. The apparatus as defined inclaim 1, wherein the FSP-R component is to assign a processor of theplatform to an alternate bit mode to facilitate stack access.
 8. Theapparatus as defined in claim 7, wherein the alternate bit mode includesa 32-bit mode.
 9. The apparatus as defined in claim 1, further includingan FSP patch manager to update the FSP-R component in response to apatch request.
 10. The apparatus as defined in claim 9, furtherincluding an FSP authentication manager to authenticate an updated FSP-Rcomponent with a public key.
 11. The apparatus as defined in claim 10,further including an FSP/FIT interface to update the FIT with an updatedentry for the updated FSP-R component.
 12. A method to improve platformefficiency, comprising: retrieving, with an instruction by a processor,a firmware support package (FSP) reset (FSP-R) component from a platformmemory; assigning, with an instruction by the processor, an entry to afirmware interface table (FIT) for the FSP-R component; assigning, withan instruction by the processor, respective entries to the FIT forauxiliary FSP components; and transferring, with an instruction by theprocessor, platform control to the FSP-R component to control executionof the auxiliary FSP components in response to a platform reset vector.13. The method as defined in claim 12, further including identifyingavailable platform resources associated with respective ones of theauxiliary FSP components.
 14. The method as defined in claim 13, furtherincluding reducing a boot duration of the platform by bypassing one ofthe respective ones of the auxiliary FSP components when respective onesof the available platform resources are available.
 15. The method asdefined in claim 13, further including invoking one of the respectiveones of the auxiliary FSP components when respective ones of theavailable platform resources are unavailable.
 16. The method as definedin claim 12, further including controlling an execution order of theauxiliary FSP components during platform boot.
 17. The method as definedin claim 12, further including verifying compatibility betweenrespective ones of the auxiliary FSP components and a platformprocessor.
 18. The method as defined in claim 12, further includingassigning a processor of the platform to an alternate bit mode tofacilitate stack access.
 19. The method as defined in claim 18, whereinthe alternate bit mode includes a 32-bit mode.
 20. The method as definedin claim 12, further including updating the FSP-R component in responseto a patch request.
 21. The method as defined in claim 20, furtherincluding authenticating an updated FSP-R component with a public key.22. The method as defined in claim 21, further including updating theFIT with an updated entry for the updated FSP-R component.
 23. At leastone tangible computer-readable medium comprising instructions which,when executed, cause a processor to at least: retrieve a firmwaresupport package (FSP) reset (FSP-R) component from a platform memory;assign an entry to a firmware interface table (FIT) for the FSP-Rcomponent; assign respective entries to the FIT for auxiliary FSPcomponents; and transfer platform control to the FSP-R component tocontrol execution of the auxiliary FSP components in response to aplatform reset vector.
 24. The at least one tangible computer-readablemedium as defined in claim 23, wherein the instructions, when executed,further cause the processor to identify available platform resourcesassociated with respective ones of the auxiliary FSP components.
 25. Theat least one tangible computer-readable medium as defined in claim 24,wherein the instructions, when executed, further cause the processor toreduce a boot duration of the platform by bypassing one of therespective ones of the auxiliary FSP components when respective ones ofthe available platform resources are available. 26-33. (canceled)